Systems and methods for managing demand driven sporting games

ABSTRACT

A demand driven game system and method uses a communications network driven by an engine to facilitate the scheduling of demand driven (sporting) games (DDG&#39;s), through passively accepting electronic expressions of interest for open slots (registrations), and actively filling slots through a matching service. Such functions can be performed through a combination of processing party preferences from a public interface, a team interface, setup preferences from an administrator interface and a referee interface, processing league data structures from a database, particularly competition rosters and referee rosters, processing DDG registrations and sending and receiving automated communications with relevant parties through SMS channels. DDG slots could be filled through a combination of transactional approaches, players/teams/individuals registering for specific slots, and service approaches, with players/teams/individuals registering to receive queries for DDG&#39;s of a specific character.

The Present invention both manages demand driven sporting games, andperforms active demand driven game-fill functions, using acommunications network.

Many people play in local sports leagues and the like in many differenttypes of sport, including for example basketball, netball, indoorsoccer, and indoor cricket.

Typically, a league or organising body will set up matches, and providegame officials and other support, and registered teams will play once aweek at a designated time in a local hall, sports centre or the like.

This ‘supply driven’ and ‘top down’ organisational approach is almostthe exclusive format of sport, such that games are at the discretion oforganising bodies, player needs to be associated with teams, teams aretold who they will play, when they play and the like, competitive gamesare played within the context of a full season, players need to sign-upat the beginning of a season etc.

This approach is becoming increasingly opposed to modern day lifestyles,such that busier lives make it more difficult to maintain a long termsport routine, particularly for those from an adult age group, andorganise that routine around the beginning of a sporting season.Moreover, these issues create barriers of entry for new players,particularly associated with season start-up times, and exclude a rangeof individuals that would otherwise enjoy the competitiveness, exerciseand social activity which are uniquely provided by sport.

Indeed, even for those who can accept the necessary commitments, andovercome the barriers to entry, there is still a requirement tosystematically sit out games through ‘byes’, not participating in finalsor the like. This is both a problem in and of itself, diminishing theplayer experience, and reflective more generally of the problemsassociated with an exclusively supply centric approach to sport.

The aim of the present invention is to provide a mechanism facilitatingdemand driven sport through the provision of demand driven game slots,which can be registered for by teams, players and individuals, which canbe implemented electronically and automatically given sufficient demand,and the provision of active matching/filling functions, which enablesteams, players and individuals to relate to demand driven games as aservice, such that said parties are actively matched by the system basedon general preferences.

Viewed from one aspect the following invention provides a demand drivengaming system for sport over an electronic communications networkincluding;

an administrative interface for setting up demand driven game (DDG)slots, and setting directly and indirectly related preferences.

a referee interface to assist in integrating referees within DDG's,including setting participation preferences and specifying availabilitytimes.

a team interface for setting participation level, by registering forspecific types of active matching, optionally providing access to toolsto register for singular DDG's, optional tools to challenge other teamsto unrecorded DDG's, viewing up-and-coming games and the like.

a public interface for registering for singular DDG's, and tools toregister for an individual active matching service.

a DDG engine for processing game registrations and verifications,processing preferences from various interfaces and processing courtavailability and performing active match processing.

a database for storing preferences, league data and the like.

The present invention may for example be implemented through a websiteon the Internet and/or through any other suitable communications system,including electronic messaging in general, and provides a system foradministrators to setup, fill and manage demand driven games (DDG's), insuch way that players/individuals might register for a particular DDG ora DDG service, or said players or teams might be approached withouthaving registered for a game or a service, particularly in situationswhere a team is uniquely scheduled not to play for a week, and queriedas to whether said team would like a replacement game in the form of aDDG organised.

The present invention assists a party, e.g. a league administrator, toorganise team members, referees, spare courts and the like, in such away that demand driven games are available as an ongoing service toplayers and individuals in various formats within existing competitionsincluding in the format of DDG bye matches, challenge matches, trainingsession, finals fillers and the like, and outside competitions in theform of public matches and the like, both for increasing the playerexperience, generating additional revenue streams for sporting leagues,encouraging new individuals to participate in the sport within theirrespective capacities, and moving sport toward a social/entertainmentalignment and away from a purely competitive alignment, thus opening upnew markets.

The ability of the system to match ‘spare’ courts, with teams interestedin playing an unrecorded game, in such a way that relevant parties areautomatically organised using interactive communications sent by thesystem, effortlessly applies otherwise wasted league resources, whilesimultaneously providing a service to players, to generate revenuestreams, which for example create revenues of $100 per game in the caseof basketball. Functions like detecting which court is ‘spare’, whichteam is ‘uniquely unscheduled’ for a week relies on the system beingmounted on, or used in association with, a sport administration package,to the extent the system has access to general purpose game rosters,i.e. lists of teams scheduled to play on particular courts. Thus thesystem may function in a standalone fashion, using full administratorspecified details, or a parasitic fashion and be attached to a sportadministration program, to the extent data structures created by saidprogram are used within the identification of ‘spare’ courts, theidentification of spare teams, and the identification of spare referees,functions which would otherwise need to be defined or disabled within anadministrative interface or the like.

The system might provide demand driven games for a range of purposes andparties, be it existing teams that have a bye and would otherwise missout on a game, be it existing teams that did not qualify for finals andwhose season would otherwise be over, be it existing teams or playersthat would like to play twice a week irrespective of whether one ofthose games is unrecorded (i.e. by registering for a specific DDG, orregistering for an active matching service for a system organised weeklyteam DDG of a specific character), be it teams that would like a formaltraining session on a competition court, be it teams that would like tochallenge another specific team to an unrecorded game, or be itindividuals without the time to participate in a league on a consistentweekly basis but who would like to play games on odd days through theweek.

The system might be both active and passive, such that passive registersfor a particular DDG might allow players or teams to express a desire toplay in said game (e.g. by adding a name to a register on a centralizedDDG web page, through a discrete team page, through a direct interface,or some other practical equivalent), or the system might activelyidentify parties with a high likelihood of accepting a DDG offer ifprompted, such as players/teams with byes, players/teams missing out onfinals, players/teams identifying themselves as wishing to play DDG's ofa particular character, or the like, and might prompt said player/teamto participate in a DDG using a range of suitable interactivecommunications, including sending an SMS to said player.

A particular demand driven gaming system might be dedicated to a singletype of sport or league, e.g. to a basketball league or to a particularsports centre or the like. The system may also be run in a more generalmanner, e.g. the system may provide a central service for managing oraccessing demand driven games for a variety of sports and/or venues.

The present invention might be particularly useful for indoor sportslike basketball but might also apply to a range of sports includingnetball, soccer (e.g. indoor soccer, including 5-a-side or 6-a-sidesoccer), indoor cricket, darts or any other team sport, particularlysports with smaller team populations. Said system might both augmentexisting sporting competitions, with filler games, extra games, trainingsessions and the like, and generate new types of competition,particularly competitions of a more social and flexible character, madefrom temporary teams, and including non-registered players (i.e. playersthat haven't before signed up to a competition and/or haven't paid theyearly registration fee).

The administrative interface is a private space for administrators tosetup DDG slots, including defining and categorizing slots according tothe desired game type (e.g. define a slot as a ‘training session’, ‘byematch’ or the like, which might be attached to categorically uniqueinitiation steps, particularly whether referees are required for the DDGtype), set the required number of registrations before a game isinitiated and whether a particular number of active confirmations arethen required prior to a game being scheduled, and access relatedpreferences for other automatic systems, including systems for activematching. The administration section might take the form of a privatewebpage, a program/application, flash code or an applet, or any othersuitable framework, provided it allows for restricted access to thesetup dimensions of the system.

The administration interface might be divided into components forcreating and setting up DDG slots, and components for managing activematching systems.

The administration interface might include fields for creating asingular DDG slot, or string of slots, within a particular venue, withinselected courts, within a specified time, or set of discrete times. Thiswould allow, for example, an administrator to setup DDG slots of aparticular DDG type for 6:15 pm and 9:30 pm on courts/venues X and Y, orsome equivalent. Once a setting of this nature was submitted to anactive list of DDG's, said slots might appear on a central public page,accessible by teams and players, such that said teams and players mightbe able to register for said slots. Setting DDG slots might also requirethe administrator to set the conditions on which the game will initiate(i.e. the number of registrations) and setting follow-up conditions whenafter a game might be scheduled (e.g. requiring second stage refereeconfirmations and/or player confirmations and/or join fees or the like,prior to a sufficiently populated DDG slot being officially scheduled).

The DDG initiation process begins when a defined number of registrationsare received for a particular DDG slot. For example, a public game mightbe set by the administrator to initiate at 12 registrations while atraining session might be set to initiate at 5 registrations. Theinitiation process might either start/schedule a game, or begin followup processes necessary to start a game. For example, a DDG slot set to‘initiate’ at 10 registrations, might for example, send outtelecommunication notifications that the game will go ahead followingthe 10^(th) registration, said message taking the form of “DDG Engine:The public game has sufficient players and will go ahead as scheduled,the game will commence at 6:55 on court 1”. The message might be sentthrough any suitable electronic device and network, including email,SMS, instant messaging, or any other system judged suitable by areasonably qualified individual.

The administration interface may also be used to setup a slot not toautomatically schedule a game following sufficient registrations, but toperform a range of pre-schedule functions. These functions might includethe confirmation or scheduling of a referee, the confirmation of partiesthat registered for the DDG, or the payment of necessary join fees priorto a DDG being scheduled.

For example, a slot requiring registerer confirmations might, sendautomated, interactive telecommunication confirmations requesting afinal reiteration of ‘yes’ or ‘no’ from all relevant parties at the10^(th) registration i.e. following sufficient population of said slot.A message to the effect of “DDG Engine: The public game has sufficientplayers to go ahead and is now taking final confirmations, please reply‘yes’ to this message if you would still like to play, and ‘no’ if not,this message will expire at 3:00 pm”, or a practically similar emailbased message requiring hyperlink confirmation, or a practicallyequivalent system using any other network device combination.

The confirmation point, i.e. required number of confirmations, afterwhich a DDG is scheduled might be separately defined within theadministrative interface. Such that a slot might be setup to require 12registrations and 8 confirmations. The purpose of the confirmationmethod is twofold, to provide additional security that a DDG will have asufficient turnout, and to assist in the sending of join fees and thelike, such that said join fees might be attached to the confirmationmessage, for example if an SMS were sent using a premium SMS channel,such that said SMS billed the receiver between $0.55 and $7.50.

Similarly a slot setup to seek confirmation from a referee may use asimilar method, such that an automated communication might sent to saidreferee requiring an iteration of availability and interest, which thesystem might use as a validation that a particular DDG can be suitablyresourced with a referee. Alternatively an active confirmation methodfor referees might be replaced with a passive database/roster search,i.e. the system performs an approximate analysis on referee sufficiencybased on a league data structure, e.g. a referee roster, for a givenslot and might alert an administrator, referee or the like only ifreferee sufficiency is in doubt. Such specifics are immaterial provideda mechanism exists within the DDG slot setup that allows for referees tobe processed within the DDG scheduling process, particular throughactive confirmations using the above defined method.

Such initiation points, and pre-schedule processes might be defined foreach DDG type/category, including separately for ‘challenge matches’(where existing team A might manually challenges team B to an unrecordedgame using tools within discrete team interfaces), ‘public matches’(where singular players can add themselves to a register and elect toplay a game within temporary teams), training sessions (where team A andteam B can book a half court each for a formal training session), activematches (where the system prompts Team A or B to play a DDG), and thelike. Thus, allowing different settings and requirements to be appliedto different types of DDG's. This would allow, for example, trainingsessions to have an altogether different initiation and schedulingrequirements and processes to that of public games.

DDG's might be further categorized for particular seasons (men's,women's etc), for a particular grades (A, B etc), and for differentindividual/player classes (registered players, non-registered players,both etc). Using these categories, and DDG type categorizations, aleague administrator might create a range of discrete slots or strings,strategically positioned and scheduled around existing competitionrosters and the like, which serve both registered players andindividuals looking for casual games. This range of categorization mightallow demand to be distributed, different groups equal access to DDG's,accommodations to be made to certain groups for marketing purposes, e.g.free registrations to players of younger ages, or making freeregistrations on Thursday as part of a promotion or the like, or thelike.

The administration interface might also include preferences relating toactively querying whether a team or player would like to participate ina particular DDG, so called ‘active matching’, wherein DDG registers areactively filled by the system through a process of identifying teams andplayers likely to accept a DDG if prompted, and using automatedcommunication to prompt said teams or players.

The process of identifying DDG interested teams and players mightutilize existing league administrative data structures, including gamerosters, finals rosters, and the like, which might be used to identifyteams and players that are scheduled to uniquely miss out on games,because of byes, finals or the like. This feature might be controllablethrough an ‘active matching’ checkbox, that when activated enables thesystem to query teams with byes, or teams not participating in finals,querying whether they would like a DDG organised for the week in whichthe team would otherwise have no game scheduled. Such a query might takethe form of an electronic message, including SMS, Email, MMS, EMS,instant message or the like, with a message to the effect of “System:Your team has no scheduled game this week, reply ‘yes’ if you would likean unrecorded replacement game organised”. Teams or parties respondingin the affirmative, or clicking on an appropriate hyperlink or the like,might be added to an active matching list, to be matched against otherteams of a similar position or teams having requested an active matchingservice, as though they had registered for said slots organically.

Active matching might also be driven by player and team preferences,such that a team or player might register for active matching as a typeof service, through selecting preferences within public or teaminterfaces, or some equivalent, to be queried when DDG's of a particularcharacter arose. Preference settings might include games of a particulartype, at a particular time, with a particular number of registeredplayers, or some combination. Using this system a player might, forexample, register to receive a join query to join a public game, as aninteractive SMS, on Thursday night after 8:00 pm following 8 otherplayers registering for said slot, with a message to the effect of“System: A DDG matching your preferences currently exists on Thursday,would you like to be added to the register?”. Such a system might alsobe represented within the administrative interface with a checkbox tothe effect of ‘allow preference based active matching’ or the like, orsome practical equivalent, for allowing administrators to specify whattype of active matching is allowable. Indeed said checkbox may eithermake visible or hide the related preference field within the teaminterface (i.e. hide or show the tool for registering for an activematching service) or may cue the system to present an apology/blockmessage to a player or team upon said party registering for the servicewhile blocked. The specific form of the feature is immaterial providedan administrator may turn on or off preference based active matching,and that this is reflected in an appropriate way within or beside fieldsfor initiating preference based active matching, e.g. within team orpublic interfaces or the like.

The administration interface might also contain fields for operationallydistinguishing between registered and unregistered players, byprocessing registered player lists or the like within the leaguedatabase, such that said player groups might be restricted entirely, orselectively from DDG slots. This might be actionable through fields fortoggling whether or not unregistered players are allowed to participatein particularly DDG types. The enabling of this preference (i.e.allowing unregistered players) would allow anyone to register for a DDG,and shift the system from being aligned with competitions (e.g.associated with players, teams and the like) to aligning with communitymembers and community demand. This might allow any individuals ofsuitable physical ability to play a game of sport, with little notice,with no previous experience.

The DDG administration interface might take any suitable form providedit singularly or compositely; offers tools to set and define DDG slots,including setting registration points, setting optional playerverification points, setting optional referee allocations andconfirmation, setting optional join fees and the like. The interfaceshould also offer tools to manage active matching, including enablingdisabling bye matching, enabling disabling finals matching, and enablingdisabling preference/demand based matching. The interface might use anysingular coding framework, or combination of frameworks (C sharp, .Net,java, flash etc), included hard coded into an electronic device,provided said interface performs the above described actions withrespect to allowing said functions to be suitably controlled by anadministrator. The interface might be related to leagues, bodiesoverseeing leagues, third party groups, or any other relevant grouplooking to setup a DDG or equivalent system.

The referee interface is a private access section for referees to setpreferences relating to DDG's. It might be centralized and accessible byall referees, or decentralized with discrete referee pages based on alogin for each referee.

Preferences from referees might be required in situations where anadministrator requests referee confirmation prior to a DDG beingscheduled, this is particularly likely for smaller leagues with morelimited referee resources. The page might take the form of a privatewebpage, a program/application, flash code or an applet, or any othersuitable framework, provided it allows for restricted access to thereferee preferences dimension of the system.

The interface might include fields allowing a referee to set theirrelation to DDG slots, including setting fields to prevent said refereefrom being allocated to DDG's generally, setting to preference saidreferee (i.e. target said referee for being allocated to DDG's), and/orallowing referees to define availability times more generally. Thepurpose of the interface is to automate and streamline refereeparticipation in DDG's where possible. For example, the settings mightbe used when a referee allocation is required, such that the DDG enginecould perform match analysis between a particular DDG slot and refereepreferences, such that a list of matches might be constructed. Usingthis list, and the associated contact details, a rolling confirmationmethod might be used to verify a referee for a particular slot.

A ‘rolling’ message is a sequentially distributed message that is sentto a party, responded to or not, and the nature of the responsedetermines the next action. For example, an answer to the negative, or amessage expiry, might cue the system to ‘roll’ the message to the nextparty, where the process is repeated, until a match is found, i.e. anaffirmative response is received. The time a party has to respond tosaid message might be 2 minutes, 5 minutes etc (depending on the messagetype), and the ‘roll’ might be indefinite, limited to 10 parties, or thelike. The roll sequence, i.e. the order of message reception, includingwho gets preferenced (i.e. asked first), is determined by rankingvariables, which might be categorical e.g. interest level as specifiedin referee preferences, or continuous, e.g. sequenced according to pastactions, such that individuals with a history of accepting DDG gameallocations might be preferenced first.

In this way the system could construct a contact list of referees,reasonably approximate with the interest level, and or likelihood ofallocation acceptance, of said referee, and using rolling messages, orsome other suitable confirmation approach, communicate and confirm areferee for a particular game.

The referee interface might take any suitable form, including acentralized web interface, decentralized web interface, directconnection interface (e.g. where referees can adjust status throughsending communications directly to the system) provided said interfaceallows referees to modify their participation with DDG's, includingdefining categorical interest, and/or availability times, to be used inthe event administrators optionally request administrator confirmationprior to game scheduling.

The team interface is a private interface for teams that might act as adecentralized means of registering for DDG's and/or used to define teampreferences, particularly preferences relating to active matching. Thisinterface might take the form of a private webpage, downloadable orcached program, a direct interface, or some other suitable framework,such that said interface includes tools to manage team interaction withthe DDG system.

This might include;

fields for viewing team DDG bookings (e.g. scheduled training sessions);

fields for making DDG bookings (i.e. registrations for specific DDG'smight be made from within the team interface);

fields for registering for an active matching service, such that a teammight specify DDG's of a particular character which the team might beprompted to participate in;

The participation tool might be particularly useful for teams that wouldlike to play routine additional games, without the burden of manuallyand repeatedly adding names to a register. It would allow, for example,a team to identify themselves as willing and interested to play againstteams with byes, in the situation where such a team needed anopposition, and/or identify the team as interested in playing additionalmatches against teams more generally, such that multiple teams with suchsettings might be matched by the system, on a particular day at aparticular time.

The active match service, driven within the team interface, might beoptionally used to replace the manual DDG registration process forteams.

It might take the form of a series of fields, relating to differentaspects of DDG character, including DDG time, DDG day, DDG date, DDGtype, opposition team season, opposition team grade etc, such that saidfields might be used singularly or compositely to define slots orsituations where said team would like to be notified, to the extent ateam is prompted of situations or slots arising that match the characterof the active match service description through a suitable communicationnetwork and electronic device combination. For example, upon a DDG slotor situation arising that matches a teams active match servicedescription an interactive communication might be sent to said teamsrepresentative (e.g. captain or the like), as an SMS or the like, with amessage to the effect of “A game matching your teams active matchdescription has appeared on Thursday night, wherein The Bears of Men's Bgrade are looking for an opposition, reply ‘yes’ if your team would liketo participate in this game”. This example describes a situation wherean existing team, ‘The Bears’, registered manually for a DDG, the DDGengine determined this action create a situation which matched a teamsactive match service description, and prompted the team with said activematch description to participate in the game. The service might also beused for matching two teams of which neither has expressed any specificinterest, e.g. registered, in a demand driven game, but who have bothexpressed general interest in playing a DDG at a particular time. Forexample, two team representatives, from two teams, might be sent similarqueries for the purpose of establishing a game match. Thus the activematching service may either partially or entirely create demand drivengames through a preference based, engine driven, telecommunicationsapproach.

Once active matching queries are sent, and the system detects sufficientteams or players for a full game, this might cue the system to performan ordinary initiation process, such that the system might eitherschedule the game, or perform pre-schedule confirmation processes, asspecified by the administrator, and as previously described. Thus theactive matching process quite literally replaces either the registrationof a singular team, or the registration of two teams, in terms of it'sprocedural position in the system. The active match service tool,allowing teams to specify preferences for active matching, might beviewed as a value added alternative to putting a name down in a registeror the like, for the purpose of driving routine DDG's.

The team interface might also include fields relating to ‘challengematches’, i.e. tools for one team to challenge another team to a DDG,and related fields for enabling or disabling challenges generally, i.e.optionally preventing a team from receiving challenges. Such a systemwould have a range of applications, including allowing teams to alignwith particular training partner teams, within the same grade or not,for ongoing ‘challenge matches’ for practice or the like, for schedulingunrecorded rematches of actual competition games, or taken to it's limitfor creating the basis of entirely demand driven leagues.

The team interface might take a range of suitable frameworks, includinga discrete team page on the internet, an application/program, and/or adirect method of interfacing with the DDG engine (including SMS's, EMS,MMS or voice messages or the like, updating preferences on a centralregister), or any or method producing an equivalent approach, to theextent said interface provides sporting teams with the tools to registerfor DDG's, and/or register for an active matching service, includingmaking specifications of the character of the active match, and/orchallenge other teams to DDG's and the like.

The public interface is a centralized register displaying all availableDDG slots, which might be used by players, teams or individuals toregister for DDG's, including preferences for accessing the activematching service for individuals.

The interface might function as the exclusive means of registering forDDG's, or work in association with other registers, including discreteteam interfaces embedded with DDG register/active matchingfunctionality, direct services for registering for DDG games, or apractically equivalent approach for expressing interest in joining a DDGusing a suitable electronic interface and/or network as judged by areasonably qualified person.

The interface might apply to a singular league and venue, or severalleagues and venues, optionally related to different sports, such that aparticular public interface might provide access to DDG's or individualactive matching services or the like for different leagues and/ordifferent sports. Thus, related fields might differ depending on thescope and framework of said interface, such that public interfacesapplying to multiple leagues might contain fields relating to, forexample, details like post codes and the like, while public interfaceapplying to multiple sports might include fields related to selectingsport type or the like. These variations are immaterial provided saidinterfaces allows appropriate access to tools for joining DDG's orregistering for individual active matching services, or equivalentservices, suitable to the electronic context to which said interface isattuned.

The interface might be structured to display a list of relevant DDGslots, or methods for populating a list of DDG slots through means of anappropriate search, such that said list might include a list of DDG'sand associated details, i.e. DDG definition data and DDG status data,including the DDG type (i.e. e.g. a training slot, public game slot,active match slot, challenge match slot or the like), fill status (i.e.the number of current registrations for a particular slot and theinitiation threshold, for example a slot coupled with the description‘5/10’ might indicate that the slot currently has 5 registrations andrequires 10 for initiation), game status (i.e. the current processingstage of the slot, including whether it is ‘open’ for registrations,‘closed’, ‘cancelled’, ‘initializing’, ‘scheduled’ or some othersuitable description of the DDG state, or processes relating to saidstate), the data and time of the slot, venue (if required), courtnumber, the names of other players or teams that have registered for theslot, or other relevant data.

This list is non-exclusive and dependent on the nature of the publicinterface, for example a public interface applying to multiple leaguesand sports might have more extensive descriptions about the sport,and/or league, and/or league location. Similarly a public interfaceconstructed as a direct service, e.g. accessible by sending SMS's to aspecific number, e.g. through a message to the effect of “Sender:basketball game Thursday”, might display information causally andselectively, through sending messages back to the sender. Thesevariations are immaterial provided said interface provides a suitablemechanism for accessing information to facilitate an individualregistering for a DDG, or active matching service. Similarly the sameinterface might allow the player/individual to make an actualregistration through a similar means, e.g. texting ‘join’ or the like,either in response to an information return, or singularly and inassociation with other game data.

Processes for registering for a DDG using a web based format mightinclude ‘join’ buttons next to DDG slots, such that players can click‘join’ to add themselves to a particular DDG register. A downloadable orcached program might use a similar method.

The public interface might also include fields relating to an activematching service, for establishing automated relationships between aplayer and the DDG engine. Associated fields make take on a similarcharacter to the active matching service described for the teaminterface, such that an individual might specify the character of a slotor situation said player would like to receive an active match query,when such a match is detected by the system, including DDG time, DDGday, DDG date, DDG type, registration numbers, attuned to a specificseason (men's, women's etc), attuned to a specific grade (B grade, Cgrade etc), attuned to a particular category of player (registered,unregistered etc) or any other variable or data relevant for receivingautomated active matching queries. For example, the active matchservice, driven by the DDG Engine, might be set by a particular playerto send a query to said player, if DDG situation arises of a ‘public’type, on Thursday night, after 8 pm, for players from the Men's Season,of players from C or D grade, and 8/10 registrations are taken. Suchmatch arising might cue the system to send a query in the form of asuitable interactive automated communication, including SMS, with amessage to the effect of “DDG Engine: A public game on Thursdayscheduled at 7:00 pm has 8/10 registrations, and matches your activematch description, reply yes if you like to be added to the register?”.As previously described the interactive message might take a range offormats and forms, use a range of electronic devices or networks,provided said message provides the recipient with the necessary capacityto add said recipient to a register or the like to participate in theDDG in question. The purpose of the active matching fields within thepublic interface is to maximize the number of players registering forDDG's, by providing mechanisms to make DDG's routine.

The public interface might take the form of a centralized web-page,downloadable application, direct access service, e.g. controllablethrough sending communications to the system by means of a suitablemessage (e.g. SMS, EMS, MMS, instant message) or any other medium,electronic device, or network which similarly facilitates theregistration of a player to a DDG slot, or equivalent service, or anactive matching service, or equivalent.

The DDG engine is a processing, integrative and communicative agent forcombining data from the various interfaces including singularly orcollectively from the administrative interface, team interface, refereeinterface and public interface, and data from the league database,including game rosters, referee rosters, as a means of scheduling DDG'sthrough a process of passively taking DDG registrations and activelyquerying potential DDG participants, to push registrations to a pointwhere a game can be scheduled.

The DDG engine includes several distinct processes, using severaldifferent algorithms. including,

An algorithm for determining whether a particular DDG is to be initiatedor cancelled, e.g. given registrations, verifications, refereeconfirmations as required.

An algorithm for identifying parties to be added to the active matchlist, including identifying parties on the basis of situation (e.g. ateam uniquely having no scheduled game) and/or a preferencesetting/situation consistency.

An algorithm for allocating referees to a particular game, includingoptionally constructing a match list for the distribution of rollingcommunication. The necessary communication usable by the engine mightuse interactive automated SMS's, emails, MMS, EMS, instant messages orthe like, such that these messages might be sent to teamrepresentatives, or relevant parties, in relevant situations, includinggame confirmations, referee confirmations, game notifications, activematch queries and the like. As specified above the system and processesperformed by the engine might be particularly useful for teams withbyes, teams missing out on finals, or teams requesting additional games,or the like, such that said teams are more likely to be interested inplaying a DDG.

The present invention will now be described in terms of a preferredsystem. It is to be understood that the particularity of theaccompanying description does not supersede the generality of thepreceding description.

In a preferred system, the DDG system would be customized for aparticular league and a particular venue, such that the publicinterface, administrative interface and team interface relate to aspecific sport and specific venue. Said interfaces might be setup asdiscrete web pages connected to the league website, accessible throughsuitable private logons and the like, such that teams and players mightuse said web-pages to register for slots, or register for an activematching service and administrators might use a discrete web page tosetup and manage said slots.

In a preferred system the DDG Engine would be connected and customizedto the league database, i.e. the database running software for managingthe sporting competition, including creating rosters, maintainingladders, creating referee schedules and the like, such that the DDGsystem might use data structures including game rosters and refereerosters, from said administration system, within the active matchprocess (to identify teams uniquely missing out on a weekly game) andreferee assign process (to identify unutilized referees that mightoversee particular demand driven games). In a preferred system the DDGsystem and sport administration system would be stored on, and processedthrough a remote server.

In a preferred system the DDG Engine would be setup with three channelsto a SMSC server, for sending and receiving standard SMS throughtelecommunication networks, and for sending or receiving premium SMSthrough telecommunications networks, such that messages from a premiumservice might be attached to an administrator designated sum, specifiedin the administration interface i.e. for a ‘joining fee’, ‘deposit’ orthe like, e.g. $2.50 optionally payable when a DDG confirmation is madeby SMS by a registerer. Emails might also be sent as a means ofcommunication directly from the server on which the DDG system ishosted.

In a preferred system the administrator would setup multiple demanddriven game types around existing competitions, such that ‘trainingslots’ might be setup immediately before a competition, ‘public game’slots and ‘active game’ slots for specific grades would be scheduledproximate to the competition related to those grades, ‘public game’slots for unregistered players might be scheduled on days without aformal competition, and/or on days more generally associated withentertainment rather than competition, e.g. Friday nights and the like,such that the distribution off DDG slots, and the categorization of saidslots, both practically distributes the demand and aligns the functionof the system with the needs of different groups, situations and targetmarkets.

In a preferred system the administrator would setup all DDG slotcategories to initiate following sufficient registrations, such thatinitiation would require no less than 80% of registrations be confirmedthrough system initiated and received SMS following sufficientregistrations being recorded, to which would be attached booking feesbilled by means of premium SMS paid by the registerer in the process ofmaking a confirmation. The registerer might be billed $2.50 perconfirmation or some other reasonable sum, which would appear on saidregisterer's mobile phone bill.

In a preferred system this process this might take the form of,individuals, players or teams registering for a DDG slot over theinternet, registration number reaching a point defined by administratorsand cueing an initiation process, said initiation process sendinginteractive confirmation SMS's to said registerer's, at least 80% ofsaid registerer's responding affirmatively to said SMS, such that anyaffirmative response bills the registerer $2.50 as a join fee,whereupon, after receiving registrations and confirmations, the systemschedules the game, and SMS notifications are sent out to all relevantparties, including registerer's, referees and the like, withnotification of game details, court number, court time and the like. Anyinterruption to this process, including in terms of insufficientregisterer's, insufficient confirmations or the like, would cue thecanceling of the game and the issuing of SMS notifications to relevantparties to that effect.

In a preferred system ‘active matching’ services would be enabled in theadministrative interface, such that the system might act proactively toinvolve teams uniquely missing out on weekly games, and to involve teamsor players identifying themselves as willing and interested toparticipate regularly in DDG's of a particular character, in a public orteam interface. In a preferred system this process might take the formof a query SMS sent to team representatives who's team is uniquelymissing out on a weekly game, or a query SMS sent to a party who'spreferences for an active matching service align with a slot orsituation, such that said SMS's for either group might be responded toin a particular way if a DDG game is desired. In a preferred systemaffirmative responses to queries directly replace registrations for aDDG slot.

Embodiments of the present invention will now be described, by way ofexample only, with reference to the accompanying drawings. It is to beunderstood that the particularity of the accompanying drawings does notsupersede the generality of the preceding description of the invention:

In the drawings

FIG. 1 is a schematic block diagram of the demand driven gaming systemand various possible features of the system;

FIG. 2 is a flow chart of the steps associated with registering for,initializing and scheduling a demand driven game;

FIG. 3 is a flow chart of the steps associated with performing activematching, i.e. system driven functions to populate DDG slots;

FIG. 4 is a flow chart of the steps involved in setting up a DDGslot/string;

FIG. 5 is a flow chart of the steps associated with setting individualpreferences for personal active DDG matching through a public interface;

FIG. 6 is a flow chart of the steps associated with setting teampreferences for team active DDG matching through a team interface;

FIG. 7 is a screen dump of the administration Interface;

FIG. 8 a is a screen dump of the Public/individual Interface;

FIG. 8 b is a screen dump of the processing screen associated with a DDGinitializing;

FIG. 9 is a screen dump of the Team Interface;

FIG. 10 is a screen dump of the Referee Interface;

Referring to FIG. 1 the system 10 uses a communications network 122driven by DDG Engine 15 to facilitate the passive and active populationand scheduling of demand driven sporting games, through processing partypreferences from referee interface 11 administration interface 12 publicinterface 13 and team interface 14, processing league data structuresfrom database 16, particularly competition rosters 161 and refereerosters 162, processing DDG registrations 141 within slot register 152and sending and receiving automated communications with relevant partiesthrough channels 181, 182 and 183. The process of scheduling a DDG mightinclude, the administrator 121 setting up an empty DDG slot throughinterface 12, said slot appearing on public interface 13 and 14, in sucha way that players 120 teams 124 and individuals 125 can register forsaid slot. The DDG might initialize S20 once a predesignate number ofregistrations 141 are received, ‘initializing’ being either schedulingthe game S29, or performing post-registration processes includingreferee confirmations S24 and/or active player confirmations S27 and/orplayer billing S28.

DDG slots might be setup categorically, i.e. as different DDG types,using interface 12, such that a particular DDG might be setup as a‘training slot’, ‘challenge slot’, ‘public slot’, ‘active slot’ or thelike, each type having categorically discrete registration points,verification points, referee and billing settings, game descriptions,and relations with the active matching system (described later) and thelike. Setting up DDG slots might include the following steps;

setting the slot time or times S42, using the ‘Slot Time’ tool depictedin FIG. 7, including whether the DDG slot is open on a singular orrecurring fashion, and the day, date and time of said slot opening, forexample, a slot or string might be scheduled for all Tuesdays at 6:30between a given date range, or for a singular Tuesday at 6:30, or allTuesdays at 6:30 barring a, or several, dates between a given daterange, or any variation. This system allows administrators to embed openDDG slots on routinely spare courts, one off spare courts, and the like.

defining the DDG game type at S43, using the ‘Slot Settings’, ‘GameType’ tool depicted in FIG. 7, such that a particular slot or stringmight be set as a ‘training slot’ for team training, a ‘public slot’open to singular players and/or unregistered individuals, a ‘challengeslot’ slot wherein said slot might be used by teams to challenge otherteams to unrecorded games, an ‘active slot’, wherein said slot isactively filled by the system (described later). Defining DDG slot gametypes is useful for distributing demand, and maintaining differentsettings for different game types.

setting/defining the DDG slot season and grade S44, using the ‘SlotSettings’ ‘Season’ and ‘Grade’ tools depicted in FIG. 7, such that saidtools allow DDG slots to be defined for particular seasons or gradesonly. This setting might be used within DDG game descriptions only, as arecommendation or the like. The setting is useful for ensuring a certainnumber of DDG's are available for each season or grade.

setting required referees S45, such that a DDG slot can be setup torequire and/or confirm referees at S24, optionally by sending automatedcommunications requiring a response to said referee at S262 throughchannel 181, such that a DDG shall optionally not initiate withoutreferee confirmation. This setting allows administrators to control DDGscheduling, such that said games might only be scheduled after a refereeis organised, thereby preventing DDG's from stripping referees fromordinary competitions.

setting required number of registrations at S46, such that a slot can besetup to initiate at varying levels of demand. This setup stage willdefine the registration point 1211 controlling how many registrations atS23, i.e. registrations 141 in slot register 152, initiate a particularDDG, either scheduling the game or cueingpost-registration/pre-scheduling processes, such as player S27 orreferee S24 confirmation.

setting required confirmations S26, such that a slot can be setup torequire secondary confirmations prior to a game being scheduled, of anumber defined by the administrator at verification point 1212 inadministration interface 12 depicted in FIG. 7 as the ‘schedule’ tool.This number might be less than the initiation point, such that a DDGmight require 12 registrations to initialize and 10 confirmations to bescheduled. Confirmations might take the form of automated interactiveSMS sent through channel 181 through SMSC 18, with a message to theeffect of “DOG Engine: Public Game X at 7:15 on Thursday is taking finalconfirmations, reply ‘yes’ if you would like to play”. Each positivereply received through channel 182 might count as a confirmation.

setting whether confirmations also bill the player at S48, this mightdetermine whether a final scheduled game notification is sent from astandard 181 or premium 183 SMS channel, such that any messages sentthrough a premium SMS channel might bill the registerer/player anywherebetween $0.55 and $7.50 to receive. Such an optional fee might allow theadministration to impose a join fee or the like, on players using thedemand driven game system.

setting whether the slot is accessible by unregistered players at S222,i.e. players that have not ‘signed up’ to the competition and paid aregistration fee or the like, such that unregistered players might beblocked at S223. If the administrator does allow unregistered playersfor all or some DDG slots, unregistered players upon registering for aslot might be added to slot register 152 at S224, as per normal.

Finally DDG slots might be given a name and submitted to an active slotlist at S49, S410 and S411, such that said list represents DDG slotswhich are accessible through public registers, or slots being processedby DDG Engine 15 i.e. taking registrations, or being used for activematching, or the like. Once slots are defined and activated S411 theymight appear in FIGS. 8 a and 9, allowing for players/individuals toregister for slots at S21, DDG Engine 15 to use said slots within ActiveMatch Processing, or teams to register for slots S211.

Other administrative settings include the enabling/disabling of teamchallenges depicted as a checkbox in FIG. 7, said checkbox might open upand unlock the ‘issue challenge’ tool within discrete team interfacesFIG. 9, such that teams might challenge other teams S3 b 2, irrespectiveof grade, to unrecorded matches, within available ‘challenge’ DDG slottypes, provided said team, or a team being challenged, has not disabledchallenges S3 b 4, resulting in block message S3 b 5. Issuing achallenge is the same procedurally as performing an active match at S35,such that the system might send a communication through channel 181 to arepresentative of the challenged team at S3 b 3, or have the challengeappear within the challenged teams private interface, to be responded toin a reasonable period of time. If said challenged team accepts thechallenge S3 b 9 the match settings are parsed to S20, where the game isinitiated according to processes attached to challenge match DDG slotsspecified in S40. If the challenged team declines the challenge anappropriate notification is given to the challenger at S3 b 8, by meansof an SMS, Email, post within the team interface, or the like.

Administrators might also control whether active matching is performedby the system, using the ‘Allow Active Matching’ tool in FIG. 7. Thistool might unlock or make visible the respective active match preferencetools depicted in public interface FIG. 8 a. and team interface FIG. 9Active matching is an automated service which actively fills DDG slots,through a process of sending queries to parties for participating in aDDG, although said parties might not have expressed a specific interestin said DDG. This might be particularly useful such that DDG Engine 15might process league roster 161 at S312 to generate a list of teamssitting out on their weekly game at S314, because of a bye (rostered sitout), because said team might have missed out on finals, or the like,and target said teams for the provision of a replacement game as a DDG.Targeting might be achieved through SMS channel 181, an email, messagewithin team interface 14, or a practical equivalent, such that saidquery might take the form of a specific game offer at S36, includingopposition and court details, when after an affirmative response to saidquery would parse game details to S20, given appropriate oppositionconfirmation.

Viewed from one aspect active matching might be regarded as a promptingsystem for encouraging and organising teams 124, players 120 andindividuals 125 to make use of demand driven gaming slots, it alsofunctions more generally as a service, such that players and teams canrequest automated queries for demand driven games matching a, orseveral, particular characters at S51 and S61, accessed throughinterface 13 or 14, depicted in FIG. 8 a and 9 respectively.

Said preferences in interface 13 might allow individuals to requestactive match queries based on slot time S52, game type S53, season S54,grade S55 and registration level (i.e. the number of registrationsrecorded for a particular slot in slot register 152) S56. Thus, forexample, an individual might request queries be sent for public games,for B grade players, at Thursday, after 7:00, when more than 8 playersare registered. In this way said player might only receive a query for aDDG of suitable character and with a reasonable chance of going ahead.Variations of this system also allow teams to request active matchqueries for bye matching only (i.e. specifically and only to play teamswith byes) at S62, finals matching only (i.e. specifically and only toplay other teams knocked out in finals) at S63. Otherwise a generalactive match service for teams might allow might for the specificationof the desired frequency of DDG's (i.e. maximum number of active matchesper week) S65, grade of DDG's (i.e. define grade range for which activematches shall be made) S66, time of I DDG (i.e. preferenced time for anactive match) S67.

When Engine 15 detects that a slot, and/or situation matches activematch preferences, said parties might be added to the active match list153, processes and allocated matches and courts at S34, and sent queriesat S361.

In situations where a single party, of a two party match, declines anactive match, while the other party accepts, the declining party shallbe added to a list S363 while the accepting team shall be reincorporatedin the active match system, for another round of matches, until a matchis found S362, or until the list is exhausted, when-after the partymissing out on the active match is notified such at S363, using anappropriate communication sent through channel 181, or an email, ordirect message within interface 13 or 14. Positive responses at S361,from both parties, cue the system to parse the active match details toS20 at S37, one negative response at S361 strikes said team from theactive match list 153, while the other party is put back in active matchlist 153 for second round matching.

Registering for DDG slots, without active matching, might be performedthrough public interface 13 and team interface 14 at S21 and S211respectively. The interfaces are depicted on FIGS. 8 a and 9 and aredesigned to allow navigation of DDG slots, through filters and the like,and registrations to be added to discrete and attached slot registers152. A slot might be registered for at S22, by selecting the appropriatebutton, and or submitting an appropriate set of preferences, within asuitable interface. A registration shall be added to the slot register152 at S224 if the player is registered. If the player is notregistered, administration preferences must be set to allow unregisteredplayers at S222, else the registration is blocked at S223 and anappropriate error message is displayed, e.g. ‘this service is only forregistered players’. At an arbitrary point before a game, e.g. 3 hoursor the like, upon the registration of the last required registration forinitiating a game at S23, the system might begin the initiating process,and display screen FIG. 8 b, indicating the progress of game initiation.If the system detects the required number of registers has not joined atS23 the game might be canceled in a suitable manner at S231. At thispoint no notification to relevant parties is required, since bothinterfaces expressly state initiation shall only begin with sufficientregistrations.

If the administrator has turned on referees at S24, the system isrequired to find a referee before proceeding further. An active orpassive method might be taken to confirm referees, using an activemethod the system processes lists of referees at S26 and generates amatch list at S27, this might be ordered according to a range ofvariables, including expressly selected availability times (e.g.inputted on interface 11, FIG. 10), congruence with a referee roster,previous allocations and the like. Once an appropriate match list iscreated, using an active method, confirmation messages might be sent tosaid referee through channel 181, an email or the like, at S2711. If thereferee responds in the negative, or does not respond within a giventime, the next referee on the match list might be queried at S2714. Ifan appropriate response is not forthcoming before the list is exhaustedthe game might be cancelled at S2715. A passive method of refereeconfirmation shall, rather than sending communications to said referee,automatically assign the top referee on the match list at S2712.Alternatively an administrator might select no administrators, and allowthe process to be handled organically at the venue.

Once referees have been processed, administrators might set the systemto require final and active confirmation at S28. This might involve thesending out of communications through channel 181 and 183 at S281, asdepicted on FIG. 8 b, to parties that registered for the slot, andrequire a specific number of affirmative responses. The number ofconfirmations is processed at S282, such that a sufficient number shallcue the system to continue, while an insufficient number shall cue thesystem to cancel the game at S231 and issue notifications to all partiesreceiving a confirmation query at S232.

Once a game has confirmed referees, and sufficient confirmations, finalnotification might be given to all relevant parties that a game has beendefinitively scheduled for a particular time. At this point theadministrator might wish to issue join fees or the like, at S29, suchthat game notifications might be sent out through a premium SMS channel183 at S291, thus charging the mobile phone of the registering party adesignated fee between $0.55 and $7.50. This might act to restrictfrivolous or irresponsible use of the system. Other billing methodsmight also be used at this stage, including merchants, or merchantsderivatives. An administrator might also use a standard SMS, without abooking fee, at S292.

Once a sufficient number of registrations have been received S23,optionally from unregistered players S221, referees have been optionallyactively S271 or passively S712 organized, game confirmations have beensent S281 and sufficient affirmative responses received S282, and finalnotifications of game scheduling have been sent S292, optionally using apremium SMS channel to attach a fee to said notification S291, a DDGslot might be internally marked as ‘scheduled’ S210 and the game statuschanged on the public and team registers to reflect such.

It is to be understood that various alterations, additions and/ormodifications may be made to the parts previously described withoutdeparting from the ambit of the present invention, and that, in thelight of the above teachings, the present invention may be implementedin software, firmware and/or hardware in a variety of manners as wouldbe understood by the skilled person.

Further it is also to be understood that the present invention might beimplemented with all, several or one of the features described,specifically including, but not limited to, being implemented as asingular system for registering for particular DDG's (i.e. without anactive matching service), a singular system making active matches (i.e.without passive DDG registers), a singular system for contacting partiesuniquely without a weekly game, and/or implemented with all or severalof the interfaces provides, such that said system might function usingan administrative and public interface only, or an administrativeinterface only, and function purely through direct contacts. Suchvariations are deemed to be within the natural variation of the system,provided said variation performs one or some of the functions previouslydescribed.

The present application may be used as a basis for priority in respectof one or more future applications, and the claims of any such futureapplication may be directed to any one feature or combination offeatures that are described in the present application. Any such futureapplication may include one or more of the following claims, which aregiven by way of example and are non-limiting with regard to what may beclaimed in any future application.

1. A demand driven game management system for sports implemented over anelectronic communications network, including: (a) a public interface forregistering for demand driven games, and active matching services; (b) ateam interface for registering for demand driven games, and activematching services; (c) an administration interface for creating demanddriven game slots and categories, and setting related preferences,including active game matching, unregistered player access and the like;(d) a referee interface for setting referee preferences andavailability; and (e) a DDG engine for processing game registrations andverifications, processing preferences from various interfaces andprocessing court availability and performing active match processing. 2.The system of claim 1 where electronic game representations areimplemented as physical sporting games, including scheduling andorganising parties by suitable notifications, by an electronic systemfollowing sufficient registrations and sub-functions designated by anadministrator.
 3. The system of claim 2, wherein sub-functions includeSMS based interactive confirmations, sent from the system to theregisterer, and responded to from the register to the system.
 4. Thesystem of claim 2, wherein sub-functions include SMS based refereeconfirmation, sent from the system to the referee, and responded to fromthe referee to the system.
 5. The system of claim 4, wherein refereeinvolvement might be predefined, specified in the referee interface orotherwise, particularly a league referee roster.
 6. The system of claim2, wherein sub-functions include join fees, deposits, or the like,applied to a player or team registering for a demand driven game, bymeans of premium SMS, credit merchant, credit based derivative, or EFTderivative.
 7. The system of claim 1, wherein said system identifiesteams exclusively or distinctly without a competition game for aparticular week, whereupon said teams are saved to and within atemporary register.
 8. The system of claim 7, wherein said temporaryregister is used as the basis of active match processing, wherein teamsare matched against other teams, and to admin defined DDG slots.
 9. Thesystem of claim 7, wherein said temporary register is used as the basisof a contact list, to send out queries to parties, enquiring whethersaid party wishes to participate in a specific actively matched game, orbe matched to a game generally.
 10. The system of claim 9, wherein saidqueries take the form of interactive SMS.
 11. The system of claim 9,wherein said queries take any direct electronic form, including instantmessaging, a PSTN derivate, email, EMS, MMS or the like.
 12. The systemof claim 7, wherein said temporary register might also be populated withplayer or teams registered for an active matching service, and who'spreference within said service align with a slot or situation to which aquery is related.
 13. The system of claim 7, wherein said temporaryregister, populated by situation or preference, is used as the basis forcreating demand driven games, such that teams within said register arematched for a game, i.e. Team A v Team B, through a suitable matchingprocess.
 14. The system of claim 1, wherein said matches are applied toa suitable court, i.e. a spare court identified by an empty demanddriven game slot.
 15. The system of claim 1, wherein suitable teammatch/court combinations are confirmed through automated electronicmessaging, as a means of gaining approval for scheduling a particulargame.
 16. The system of claim 15, wherein active match confirmations aremade by means of SMS.
 17. The system of claim 15, wherein active matchconfirmations are made using any suitable electronic device/networkcombination, including instant messaging, email, EMS, MMS, a PSTNderivate, or a practical SMS equivalent.
 18. The system of claim 1,wherein said team interface allows said team to directly register for aparticular demand driven game, i.e. slot X on day X.
 19. The system ofclaim 1, wherein said team interface allows a team to enter preferenceswhich affect an ongoing relation with the system; such that said teammight register to auto-register for, be notified of, or the like, ademand driven game of a, or several, particular characters, as saidgames arise.
 20. The system of claim 1, wherein said team interfacemight allow for the challenging of another team to an unrecorded demanddriven game, such that a challenge might be made generally, or tuned toa specific court and time.
 21. The system of claim 1, wherein saidpublic interface allows an individual to directly register for aparticular demand driven game, i.e. game X on day X.
 22. The system ofclaim 1, wherein said public interface allows an individual to enterpreferences which affect an ongoing relation with the system; such thatsaid individual might register to auto-register for, be notified of, orthe like, for a demand driven game of a, or several, particularcharacters, as said games arise.
 23. The system of claim 1, wherein thesystem response to an identified active match is a SMS notification tothe relevant party that a DDG exists that matches an active match ruledescription.
 24. The system of claim 1, wherein the system response toan identified active match is a email notification to the relevant partythat a DDG exists that matches an active match rule description.
 25. Thesystem of claim 1, wherein the system response to an identified activematch is an updated register on a relevant web page.
 26. The system ofclaim 1, wherein the system response to an identified active match is anautomatic registration of the relevant party to the DDG that matches anactive match rule description.
 27. The system of claim 1, wherein saidreferee interface allows for setting preferences relating to whether ornot a referee will be matched to a DDG.
 28. The system of claim 1,wherein said referee interface allows for setting availability times forparticipating in a demand driven game.
 29. The system of claim 1,wherein said administration interface allows an administrator to turn onor off a system for populating DDG's that does not rely on specificexpression of interest for specific games.
 30. The system of claim 1,wherein said administration interface allows said administrator tocontrol whether or not unregistered player are allowed access to DDG'sgenerally.
 31. The system of claim 1, wherein DDG slots can be createdwhich align with actual spare slots (courts and times).
 32. The systemof claim 1, wherein DDG slots might be categorical, such that said slotsapply discretely to a particular game type, e.g. a public game, atraining session, an active match game, a challenge match, or the like,such that registering for a particular slot is synonymous withregistering for a particular type of DDG.
 33. The system of claim 1,wherein empty DDG slots might have attached registration points,specified by an administrator or otherwise, such that said registrationpoint might represent the demand point at which a game initiates. 34.The system of claim 1, wherein empty slots might have attachedconfirmation points, specified by an administrator or otherwise, suchthat said confirmation point might represent the number ofconfirmations, i.e. positive responses from a registerer made inresponse to a confirmation request from the system, required before agame is scheduled.
 35. The system of claim 1, wherein empty slots mighthave attached join fees, such that an administrator might specify anamount charged to a player, as a deposit or the like, for registeringfor, or confirming interest in, a demand driven game.
 36. The system ofclaim 1, wherein said fees are charged by means of a premium SMS. 37.The system of claim 1, wherein said fees are charged by means of creditmerchant, credit based derivative, or EFT derivative.
 38. The system ofclaim 1, wherein said engine is used to process whether a demand drivengame slot, and associated actions of registers and the like, meetsrequirements designated by administrators, or the like, includingcategorizing the sufficiency of registerers, the sufficiency ofconfirmations, the sufficiency of deposits, and/or other requirements,such that said process effects whether a demand driven game meetsadministrator requirements necessary for said game to be scheduled. 39.The system of claim 1, wherein said engine can identify teams uniquelynot playing for a particular week and add said teams to a matchingregister.
 40. The system of claim 1, wherein said engine can use teamand player preferences as a means of adding said teams and players to amatching register.
 41. A method of scheduling demand driven sportinggames using an electronic communications network, including the stepsof: providing a setup interface to create DDG slots or equivalents to beused for DDG games; providing a player or team interface for takingexpressions of interest in joining a particular game, or, takingexpressions of interest in joining games of a particular character i.e.a join service; providing a mechanism to process registrations and otherdata including providing a mechanism for automatically determiningwhether conditions exist which match admin defined conditions for whichDDG's might be scheduled. providing a mechanism to schedule gamesincluding communicating ‘scheduled’ status to relevant parties.
 42. Ademand driven game management system, including: a public interface fora player or individual to register for a demand driven game and/ordemand driven game service; and/or a team interface for a team toregister for a demand driven game and/or demand driven game service;and/or a referee interface for a referee to discretely define a relationto the DDG system and/or define availability times; and/or anadministration interface for an administration to define DDG's andrelated preferences, optionally including whether or not to allow activematching and/or the allowing of unregistered players to participate inDDG's; and/or a DDG engine for identifying whether conditions exist fora DDG game to be scheduled, and for performing necessary communicationsand confirmation during and after which.
 43. A demand driven gamemanagement system for sports implemented over an electroniccommunications network, including: (a) an administration interface forcreating demand driven game slots and categories, and setting relatedpreferences, including active game matching, unregistered player accessand the like, (b) any one or more of the following interfaces: (i) apublic interface for registering for demand driven games, and activematching services, (ii) a team interface for registering for demanddriven games, and active matching services, (iii) a referee interfacefor setting referee preferences and availability, and (c) a DDG enginefor processing game registrations and verifications, processingpreferences from various interfaces and processing court availabilityand performing active match processing.